I consider it a nice hidden feature that you can create named terminals just by going to the URL, so it would be a shame to lose it. Do you know if there's an issue open about it on xtermjs? I think it should be technically possible for the server side to close down the connection and indicate to xtermjs that it's deliberately being closed.

@takluyver I didn't find a relevant issue on xtermjs. In xtermjs, the onclose handler doesn't check the websocket CloseEvent at all, probably because the property values of this event may be browser specific:

I can get "wasClean == true" if I let the client initiate the close() and the server finish with a close() (which is spec). I get a "true" on chrome but not on firefox if the server initiates the close()

Implementing such a feature in xtermjs will require lots of testing.

I consider it a nice hidden feature that you can create named terminals just by going to the URL

I agree if the creation is triggered by a http GET request, not by a websocket handshake. Usually the websocket is managed automatically in the background which the user has no direct control on.

I agree with this sentiment: starting a terminal should be an HTTP request, not a websocket request.

What would folks think about a special named path like /terminals/new that would create a new terminal?

That seems reasonable to be, but only if it redirected you to a new numbered terminal url.

Seems reasonable to me too. Maybe add to jupyter_server as well 😉

I feel like I'm missing some context. How is this different than a POST against /api/terminals? Are you talking about bringing your own terminal names (rather than numbers) this way? Could someone elaborate a bit more on this? Thanks.

This would be a URL you visit in your browser, a GET that gives a 302 to a named terminal URL.